This disclosure relates generally to computer-based mechanisms for monitoring activity of a business application, and more particularly to an infrastructure for monitoring local events of a distributed business application.
Business applications, such as CRM or ERP applications, usually lack communications necessary to be able to monitor business activity of the application. One comprehensive solution is the Business Activity Monitoring (BAM) provided by SAP AG to monitor events of business impact within an executing business application, and deduce actions if necessary. BAM can span both the applications of an application system landscape as well as the application orchestration layer, i.e. the integration processes.
A solution such as BAM introduces the notion of a monitoring process. A monitoring process collects events raised by diverse sources and deduces action items to be completed by business experts. Processes are predefined using an Integration Builder (IB) tool or the like, and work items are created as a consequence of process execution.
BAM knows a number of event systems and is capable of connecting them. Applications spawn workflow events (or local events) to trigger follow-up actions within one SAP system (client). BAM allows to map these local events via the local event infrastructure into global events (i.e. monitoring events) that can be communicated across system borders.
BAM also introduces the concept of a monitoring event. A monitoring event is a notification sent to the monitoring process about a significant state change in the business application system. In SAP's XI, the transport medium of monitoring events are XI messages, and the transport mechanism is the XI messaging infrastructure. BAM enriches the scenario of event resolution with stateful processes and correlation of monitoring events.
An application can discharge monitoring events using message communication, and therefore a monitoring event also represents a message interface that refers to message type, etc. Each already existing message communication can be used to supply monitoring processes with information. Additional monitoring events are necessary when no message communication exists already.
Events can be used to enable application systems to fire monitoring events to eventually produce an event resolution. Event resolution in a basic sense means that an application detects invalid business data or some deadline that has been reached in a workflow event, and an alert is dispatched. This alert will be used by an event resolution framework (i.e. an Event Resolution Center, or “ERC”) to generate a resolution to the workflow event. Thus, the application alone must be able to detect the inconsistent or incorrect state of the application data. In some cases, the application will not be able to detect such inconsistencies because it may need additional data from other systems, or because one monitoring event alone does not lead to an alert that is visible to an end-user. In such cases, a monitoring process should be used.
Conditions defined in conventional tools such as an IB support only a subset of the functionality provided by the proven Business Workflow condition component. Both integration process designers and XI administrators configuring integration scenarios have been restricted by this limitation. The need for a unified condition definition and execution environment—one that provides the same set of functionality on all levels—becomes even more urgent in light of BAM.
Conditional behavior is an integral part of business monitoring processes. Designers require full expressiveness to compare key figures or deadlines in a meaningful way. The user currently has to normalize conditions before being able to define them in a definition tool, which is cumbersome when the condition exceeds a certain level of complexity. Conditions can cause runtime exceptions due to missing type checks in the definition environment.
Presently, a condition editor is used at various places in the IB for activities such as Receiver Determination., Interface determination and BPM. Condition creation is done in a tabular fashion using the following general rules: 1) For every new expression a new row is inserted into the table; 2) Only following operators are supported: =, !=, ˜, EX; 3) Extra UI symbols are provided in the first column of the table to represent parentheses, however complex conditions become practically unreadable; 4) Nesting of parenthesis is not supported; and 5) A facility for using variables in a condition is not supported.
All this make the process of creating conditions complex and error prone with almost negligible help provided by the system. The number of operators that can be supported are very few, which fails the basic idea of providing users like process designers and XI administrators with a flexible, easy to use and full blown condition building experience. Hence, a need arises to have an extensive, easy to use and more readable condition editor UI.